Any object can be linked, correlated, associated, differentiated, or in some manner categorized with respect to a different object to form implicit or explicit inter-object relationships. For instance, in an organization, a person typically has implicit and explicit relationships with other people in the organization, organizational resources (e.g., printers, facilities, etc.), geographical locations, business units, club memberships, and so on. Each implicit and/or explicit relationship between respective objects (i.e., the person, the other people, a resource, etc.) represents a respective hierarchical data relationship.
For example, one hierarchical data relationship is represented by each person within the company that has access to a specific resource (e.g., a building on the company campus, a room, a printer, etc); the resource being the root node of the hierarchy and the individuals with access to the resource being the leaves. Another hierarchical data relationship is represented by individuals that make up the management structure of the company. Other inter-object data relationships may represent a hierarchy of individuals within a particular business unit, all employees of the company that have specialized training, and so on.
Unfortunately, even though a data store can be configured to some extent by a network administrator to represent inter-object relationships within hierarchies of other data, complex inter-object relationships (e.g., such as those representing a single object within more that one hierarchy) are not simply and adequately represented using conventional data store (e.g., directory, database, etc.) systems and technologies. (Traditional directories include those based on the well-known X.500 standard and the Lightweight Directory Access Protocol (LDAP).
To illustrate this limitation of traditional data store systems and technologies, consider that a directory typically represents inter-object relationships using rigid data naming and inflexible directory schemas. Objects or nodes in the directory are organized within a single hierarchy with a root node at the top of the hierarchy. The root node has a name. Each other node in the directory is named based on its direct naming relationship to the root node and also with respect to each intervening node in the respective node's hierarchy. As a result, if a parent object is renamed in a single operation, any objects that are subordinate or children of the parent object are also renamed in that same single operation. This is because an object's full “distinguished name” includes the name of each parent object(s) all the way down the line to the root node's name.
It is the full distinguished name of an object that also represents its static location or data relationship with respect to each other object in the data store. Thus, an object's distinguished name inflexibly inter-tangles object naming within a single hierarchy with inter-object relationships in that hierarchy. Because of this, any navigation of the data store must be performed from top-to-bottom to determine and subsequently present any inter-object relationships—that is from the root object, to a parent object to any subordinate child object(s).
Because traditional data stores (e.g., directories, databases, and so on) rely on a carefully specified and inflexible object naming scheme to identify inter-object relationships, an administrator configuring the data store requires a-priori knowledge of the inter-object relationships when configuring the data store. Additionally, any configuration of the data store must consider not only the proper representation of inter-object relationships in the data store, but must also consider the heuristics that a search engine requires to navigate the data store.
To make matters worse, elastic data relationships are not easily described, represented, or navigated using conventional data store systems and techniques. An elastic data relationship is one wherein the relationship is derived from data that defines an object at any point in time. This means that over time elastic data relationships can be dynamic. For instance, consider the following non-obvious and potentially elastic data relationships: a Web site and the Web pages that make up the Web site, a customer and the individuated services that the customer purchases from a merchant, a personal computer (PC) and peripheral devices that are coupled to the PC, a city and the districts within the city, a business and the business' contacts, an employee and the employee's dependents, and the like.
These non-obvious and potentially elastic data relationships are not easily represented because whenever a one-to-one correspondence between a surface object and corresponding sub-objects needs to be represented in the data store, an irreversible design choice must be made. (Conventional practice is to strictly control directory schema updates due to the serious nature of directory schema modification). A network administrator can opt for “total incorporation” of the sub-objects into the particular object by representing the sub-objects as attributes of the surface object in the directory schema. Or the network administrator can opt for “total distinction” of each object, by creating separate objects in the schema for sub-object components, and positioning the separate objects subordinate to the surface object.
To illustrate this irreversible design choice, consider that a particular network router includes multiple router modules plugged into the router's backplane. Information about the router and the router modules are typically stored in a directory in one or two different fashions—each of which may be equally unsatisfactory depending on how entities and their respective relationships to other entities are represented. One design choice is to characterize a router and its corresponding router modules as a single hierarchical data structure representing the network router as a parent object, and the corresponding router modules as child objects that are subordinate to the parent object. A different design choice is to characterize the router and the router's associated router modules as a single parent object with complex attributes. The parent object represents the router (backplane), and the complex attributes represent the respective router modules that are hosted by the router.
In consideration of the first design choice, depending how the router and the modules are configured, collapsing information about the router modules, or boards onto the backplane may prove unwieldy. This is because the functionality of the router's backplane may be small as compared to the functionality of the network router modules hosted by the router. Whereas considering the second design choice, completely separating the boards from the backplane may be equally unsatisfactory because the router is still a single physical router box that generally includes a number of router modules.
Both of the described solutions to representing data relationships with an inflexible directory schema are time consuming to implement and counter-intuitive. The semantics of shape and naming in the directory must be agreed on in advance to solve the simplest design problem. Thus, whenever a one-to-one correspondence between an entity and corresponding sub-entities needs to be represented in a traditional directory, an irreversible and inflexible design choice must be made within the directory schema.
Whichever design choice is selected, the data store and tools used to navigate, search and present objects within the data store with respect to inter-object relationships have been substantially limited. This is because the data store itself can not represent all of the possible implicit and explicit inter-object relationships of an object. This is considered by many computer programmers to be one of the most intractable problems of directory schema in traditional directories. This is also deemed to be the reason that computer program applications are not typically portable across directory platforms or even directory instances.
To further worsen matters, recent developments in information technology provide network administrators with opportunities to tie disparate data stores (e.g., databases, directories, and so on) of data together into a single logical directory or “metadirectory”. Such disparate databases and directories include, for example, information corresponding to enterprise users, tangible and intangible resources, financial information, corporate e-mail systems, network operating systems, and so on.
Metadirectories present network administrators with complex and often elastic object data relationships that cannot be simply or adequately described, represented, navigated, or presented using traditional systems and procedures to configure and manage data stores. Considerable efforts are required on the part of the administrator (or a staff of administrators) to configure a data store. Manually determining and implementing such inter-object relationships (whether they be dynamic or not) is fraught with the potential for human error and oversight. Furthermore, database administrators with an appropriate level of such knowledge to perform such a directory configuration are expensive.
The following described subject matter addresses these and other problems of representing inter-object relationships.